Архитектура ОС

Тупики

Архитектура ОС

План лекции

1. Понятие тупика (взаимной блокировки)

2. Необходимые условия возникновения тупика

3. Моделирование тупиков: граф ресурсов

4. Методы обработки тупиков

5. Предотвращение тупиков

6. Избегание тупиков: алгоритм банкира

7. Обнаружение и восстановление после тупиков

8. Комбинированные подходы и практические примеры

Тупики
Архитектура ОС

1. Понятие тупика

Тупик (deadlock) — ситуация, при которой группа процессов блокирована навсегда, причем каждый процесс ожидает событие, которое может быть вызвано только другим процессом из этой же группы.

Характеристики:

  • Постоянная блокировка — процессы никогда не разблокируются без вмешательства
  • Циклическая зависимость — процессы образуют цикл ожидания
  • Потеря производительности — система теряет рабочие процессы
  • Необходимость вмешательства — требуется внешнее воздействие для разрешения
Тупики
Архитектура ОС

Пример тупика

Процесс A удерживает R1 и запрашивает R2
Процесс B удерживает R2 и запрашивает R1

Оба процесса заблокированы навсегда!

Процесс A:

  1. Запросил R1 — получен
  2. Запросил R2 — ожидает
  3. Не освободит R1

Процесс B:

  1. Запросил R2 — получен
  2. Запросил R1 — ожидает
  3. Не освободит R2
Тупики
Архитектура ОС

2. Условия Кофмана (4 необходимых условия)

Тупик возможен только при одновременном выполнении всех четырёх условий:

  1. Взаимное исключение — ресурс назначен ровно одному процессу
  2. Удержание и ожидание — процесс удерживает ресурс и ожидает другие
  3. Отсутствие вытеснения — ресурс нельзя изъять принудительно
  4. Циклическое ожидание — цепочка процессов образует цикл
Тупики
Архитектура ОС

Взаимное исключение

Каждый ресурс либо доступен, либо назначен ровно одному процессу.

  • Если ресурс занят — другие процессы не могут его использовать
  • Типичные примеры: принтер, мьютекс, файл на запись
  • Нарушение возможно только для совместно используемых ресурсов (файлы только для чтения)
Тупики
Архитектура ОС

Удержание и ожидание

Процесс удерживает хотя бы один ресурс и ожидает получения дополнительных ресурсов, удерживаемых другими процессами.

  • Процесс не освобождает уже полученные ресурсы
  • Одновременно запрашивает новые
  • Классический сценарий: «держу R1, жду R2»
Тупики
Архитектура ОС

Отсутствие вытеснения

Ресурс может быть освобождён процессом только добровольно.

  • ОС не может принудительно изъять ресурс
  • После завершения работы с ресурсом процесс сам его освобождает
  • Прерываемые ресурсы (CPU, память) допускают вытеснение
  • Непрерываемые (принтер, ленточный накопитель) — нет
Тупики
Архитектура ОС

Циклическое ожидание

Существует цепочка процессов {P1,P2,,Pn}\{P_1, P_2, \ldots, P_n\}:

P1P2P3PnP1P_1 \to P_2 \to P_3 \to \ldots \to P_n \to P_1

  • P1P_1 ожидает ресурс, удерживаемый P2P_2
  • P2P_2 ожидает ресурс, удерживаемый P3P_3
  • PnP_n ожидает ресурс, удерживаемый P1P_1
Тупики
Архитектура ОС

3. Граф распределения ресурсов

Граф ресурсов — наглядное представление состояния системы:

  • Круги — процессы (P1,P2,P_1, P_2, \ldots)
  • Квадраты — ресурсы (R1,R2,R_1, R_2, \ldots)
  • Дуга PiRjP_i \to R_j — процесс запрашивает ресурс
  • Дуга RjPiR_j \to P_i — ресурс удерживается процессом

Тупик существует     \iff в графе есть цикл (для одного экземпляра каждого ресурса)

Тупики
Архитектура ОС

Пример графа ресурсов

    P1 ──запрос──▶ R1 ──удержание──▶ P2
    ▲                                  │
    │                                  ▼
    R2 ◀──удержание── P3 ◀──запрос── R2

Цикл: P1R1P2R2P1P_1 \to R_1 \to P_2 \to R_2 \to P_1

Наличие цикла = тупик

Тупики
Архитектура ОС

4. Обзор методов обработки тупиков

  1. Игнорирование — надеяться, что не возникнет

  2. Предотвращение — нарушить одно из условий Кофмана

  3. Избегание — динамический анализ безопасности состояний

  4. Обнаружение и восстановление — разрешить тупик, затем устранить

Тупики
Архитектура ОС

5. Предотвращение: нарушение взаимного исключения

Идея: сделать ресурсы совместно используемыми, если возможно.

  • Файлы только для чтения —共享 для всех процессов
  • Неизменяемые структуры данных
  • Принтеры с очередью печати (spooling)

Ограничение: не всегда применимо из-за физических ограничений ресурсов

Тупики
Архитектура ОС

Предотвращение: нарушение удержания и ожидания

Идея: запретить процессам удерживать ресурсы при запросе новых.

Реализация:

  • Процесс запрашивает все ресурсы до начала работы
  • Или освобождает всё перед запросом новых

Проблемы:

  • Голодание процессов
  • Неэффективное использование ресурсов
  • Сложность предсказания потребностей
Тупики
Архитектура ОС

Предотвращение: введение вытеснения

Идея: позволить системе принудительно изымать ресурсы.

Применимо:

  • CPU — вытесняющая многозадачность
  • Память — swap / paging

Не применимо:

  • Принтер в середине печати
  • Блокировка базы данных
Тупики
Архитектура ОС

Предотвращение: нарушение циклического ожидания

Идея: упорядочить все типы ресурсов и требовать запросы в строгом порядке.

  • Каждому типу ресурса назначается номер: R1,R2,,RmR_1, R_2, \ldots, R_m
  • Процесс может запрашивать RiR_i только если не удерживает RjR_j, где jij \ge i
  • Гарантированно предотвращает циклическое ожидание
  • Простая реализация
Тупики
Архитектура ОС

6. Концепция безопасного состояния

Состояние системы — безопасное, если существует последовательность выполнения процессов, при которой все процессы могут завершиться без тупика.

Безопасная последовательность {P1,P2,,Pn}\{P_1, P_2, \ldots, P_n\}: для каждого PiP_i ресурсы, которые он может запросить, удовлетворяются из доступных + освобождённых всеми PjP_j (j<ij < i).

  • Безопасное состояние \Rightarrow тупик невозможен
  • Небезопасное состояние ⇏\not\Rightarrow тупик обязателен
Тупики
Архитектура ОС

Алгоритм банкира

Алгоритм избегания тупиков на основе концепции безопасного состояния.

Структуры данных (nn процессов, mm типов ресурсов):

  • Available [m][m] — количество доступных экземпляров каждого ресурса
  • Max [n×m][n \times m] — максимальные потребности каждого процесса
  • Allocation [n×m][n \times m] — текущее распределение ресурсов
  • Need [n×m][n \times m] — оставшиеся потребности

Need[i,j]=Max[i,j]Allocation[i,j]Need[i,j] = Max[i,j] - Allocation[i,j]

Тупики
Архитектура ОС

Алгоритм безопасности

  1. Инициализация: Work=AvailableWork = Available, Finish[i]=falseFinish[i] = false
  2. Найти ii: Finish[i]=falseFinish[i] = false и NeediWorkNeed_i \le Work
    • Если нет такого ii — перейти к шагу 4
  3. Work=Work+AllocationiWork = Work + Allocation_i, Finish[i]=trueFinish[i] = true, перейти к шагу 2
  4. Если Finish[i]=trueFinish[i] = true для всех iiсистема в безопасном состоянии
Тупики
Архитектура ОС

Алгоритм запроса ресурсов

При запросе RequestiRequest_i от процесса PiP_i:

  1. Если RequestiNeediRequest_i \le Need_i — перейти к шагу 2. Иначе — ошибка
  2. Если RequestiAvailableRequest_i \le Available — перейти к шагу 3. Иначе — PiP_i ждёт
  3. Пробное распределение:
    • Available=AvailableRequestiAvailable = Available - Request_i
    • Allocationi=Allocationi+RequestiAllocation_i = Allocation_i + Request_i
    • Needi=NeediRequestiNeed_i = Need_i - Request_i
  4. Выполнить алгоритм безопасности:
    • Безопасно → подтвердить распределение
    • Небезопасно → откатить, PiP_i ждёт
Тупики
Архитектура ОС

7. Обнаружение тупиков: когда использовать?

  • Алгоритм избегания слишком дорог по накладным расходам
  • Тупики возникают редко
  • Нет априорной информации о максимальных потребностях процессов
  • Система допускает восстановление после тупика
Тупики
Архитектура ОС

Обнаружение: один экземпляр ресурса

Используется граф ожидания (wait-for graph):

  • Узлы — процессы
  • Дуга PiPjP_i \to P_j: PiP_i ожидает ресурс, удерживаемый PjP_j

Тупик существует     \iff в графе ожидания есть цикл

Обнаружение цикла — поиск в глубину (DFS), O(n2)O(n^2)

Тупики
Архитектура ОС

Обнаружение: несколько экземпляров ресурса

Алгоритм, аналогичный алгоритму безопасности:

  1. Work=AvailableWork = Available, Finish[i]=falseFinish[i] = false для всех ii
  2. Найти ii: Finish[i]=falseFinish[i] = false и RequestiWorkRequest_i \le Work
    • Если нет — перейти к шагу 4
  3. Work=Work+AllocationiWork = Work + Allocation_i, Finish[i]=trueFinish[i] = true, перейти к шагу 2
  4. Если Finish[i]=falseFinish[i] = false для некоторого iiпроцесс PiP_i в тупике
Тупики
Архитектура ОС

8. Восстановление: прерывание процессов

Подход: прервать один или несколько процессов для разрушения цикла.

Критерии выбора «жертвы»:

  • Приоритет процесса
  • Время выполнения
  • Количество удерживаемых ресурсов
  • Число процессов, которое нужно прервать
Тупики
Архитектура ОС

Восстановление: откат и изъятие ресурсов

Откат процессов:

  • Возврат к контрольной точке
  • Перезапуск с безопасного состояния
  • Необходимость регулярного сохранения чекпоинтов
  • Потеря проделанной работы

Изъятие ресурсов:

  • Принудительный отбор у процесса
  • Применимо только к прерываемым ресурсам
  • Процесс может быть приостановлен и возобновлён
  • Не работает для непрерываемых ресурсов
Тупики
Архитектура ОС

Комбинированные подходы

Иерархическая структура ресурсов — разделение на классы:

  • Критические ресурсы — строгое предотвращение
  • Некритические ресурсы — обнаружение и восстановление
  • Восстанавливаемые ресурсы — избегание

Адаптивные стратегии — динамический выбор в зависимости от:

  • Текущей нагрузки системы
  • Важности процессов
  • Истории возникновения тупиков
  • Доступных ресурсов
Тупики
Архитектура ОС

Практические примеры: UNIX и Windows

UNIX / Linux:

  • Игнорирование в пользовательском пространстве
  • Предотвращение в ядре
  • Сигналы для прерывания процессов
  • Таймауты при ожидании ресурсов

Windows:

  • Комбинированный подход
  • Упорядочение системных ресурсов
  • Таймауты при ожидании объектов
  • Обнаружение блокировок потоков
Тупики
Архитектура ОС

Практические примеры: базы данных

Стратегия: обнаружение и восстановление с поддержкой транзакций.

  • Отслеживание зависимостей между транзакциями
  • Выбор жертвы для отката (по приоритету/времени)
  • Сохранение контрольных точек транзакций
  • Автоматический перезапуск отвергнутой транзакции
  • Свойство ACID: Atomicity гарантирует корректный откат
Тупики
Архитектура ОС

Заключение

Тупики
Архитектура ОС

Ключевые выводы лекции

  • Тупик — permanent блокировка группы процессов в цикле ожидания

  • 4 условия Кофмана — необходимы все одновременно

  • Предотвращение нарушает одно из условий

  • Алгоритм банкира гарантирует избегание через безопасные состояния

  • Обнаружение через графы ожидания или алгоритм, аналогичный алгоритму безопасности

  • Нет универсального решения — выбор зависит от системы

  • На практике чаще всего применяется игнорирование + перезагрузка

  • Комбинированные подходы — наиболее гибкие

Тупики
Архитектура ОС

Вопросы для самоконтроля

  1. Дайте определение тупика (взаимной блокировки).
  2. Сформулируйте четыре необходимых условия Кофмана для возникновения тупика.
  3. Как граф распределения ресурсов используется для моделирования тупиков?
  4. В чём разница между предотвращением и избежанием тупиков?
  5. Опишите алгоритм банкира и его структуры данных.
  6. Как работает алгоритм обнаружения тупиков с несколькими экземплярами ресурсов?
  7. Какие методы восстановления после тупиков существуют?
  8. Какие стратегии обработки тупиков применяются в UNIX и Windows?
Тупики
Архитектура ОС

Рекомендуемые ресурсы

Основная литература:

  1. Таненбаум Э., Бос Х. Современные операционные системы. 4-е изд.
  2. Столлингс В. Операционные системы. 9-е изд.

Дополнительная литература:

  1. Silberschatz A., Galvin P., Gagne G. Operating System Concepts. 10th ed.
  2. Таненбаум Э., ван Стеен М. Распределённые системы. Принципы и парадигмы.
Тупики

Представляем план лекции. Перечислим основные темы: от определения тупика до практических примеров обработки в реальных системах.

Начинаем с базового определения тупика. Подчеркните: это не замедление, а полная permanent блокировка группы процессов.

Классический пример с двумя процессами и двумя ресурсами. Покажите пошагово, как возникает взаимная блокировка.

Переходим к условиям Кофмана — теоретической основе анализа тупиков. Все четыре условия должны выполняться одновременно, иначе тупик невозможен.

Первое условие. Приведите примеры: принтер, мьютекс, файл на запись — ресурсы, которые не могут быть разделяемыми.

Второе условие — процесс «держит своё и просит чужое». Это ключевой паттерн, ведущий к тупику.

Третье условие. Сравните вытесняемые ресурсы (CPU, память) и невызываемые (принтер, БД-блокировка).

Четвёртое условие замыкает круг: процессы образуют кольцо ожидания. Покажите математическую запись цикла.

Граф ресурсов — наглядный инструмент моделирования тупиков. Обратите внимание на обозначения: круги — процессы, квадраты — ресурсы.

Разбираем конкретный пример графа. Цикл в графе однозначно указывает на тупик при одном экземпляре каждого ресурса.

Четыре стратегии обработки тупиков: от простого игнорирования до обнаружения и восстановления. Каждая имеет свои компромиссы.

Начинаем блок предотвращения. Первая стратегия — сделать ресурсы совместно используемыми. Spooling для принтера — классический пример обхода взаимного исключения.

Вторая стратегия: заставить процесс запрашивать все ресурсы сразу. Простая идея, но ведёт к неэффективному использованию ресурсов и возможному голоданию.

Третья стратегия: разрешить ОС принудительно изымать ресурсы. Работает для CPU и памяти, но не для принтера в середине печати.

Четвёртая стратегия — нумерация ресурсов и строгий порядок запросов. Гарантированно устраняет циклы, используется в некоторых ядрах ОС.

Ключевое понятие для избегания тупиков. Безопасное состояние означает, что система гарантированно может завершить все процессы без тупика.

Алгоритм банкира — классический метод Дейкстры для избегания тупиков. Объясните аналогию с банком, выдающим кредиты.

Пошаговый алгоритм проверки безопасности. Ищем процесс, который может завершиться, и моделируем освобождение его ресурсов.

Как система обрабатывает запрос ресурса от процесса. Пробное распределение + проверка безопасности — двухфазный подход.

Когда алгоритм банкира слишком дорог по накладным расходам — используем обнаружение. Обсудите, в каких случаях это оправдано.

Для одного экземпляра ресурса используем граф ожидания. Поиск цикла через DFS — простая и эффективная проверка за O(n²).

Обобщение на несколько экземпляров ресурса. Алгоритм аналогичен проверке безопасности, но использует текущие запросы процессов.

Обнаружили тупик — что делать? Простейший способ — прервать процесс. Обсудите критерии выбора «жертвы»: приоритет, время, ресурсы.

Более тонкие методы восстановления: откат к контрольной точке и принудительное изъятие ресурсов. У каждого метода есть ограничения.

На практике применяют комбинации стратегий. Иерархия ресурсов позволяет выбрать оптимальный метод для каждого класса.

Реальные примеры из UNIX/Linux и Windows. Обе ОС используют комбинации стратегий, но с разными акцентами и приоритетами.

СУБД — классическая область, где тупики возникают часто. Транзакции и ACID-свойство Atomicity позволяют безопасно откатывать изменения.

Переходим к заключительной части. Подведём итоги лекции и сформулируем ключевые выводы.

Главный вывод: нет универсального решения. Выбор стратегии зависит от требований системы и характера ресурсов. На практике чаще всего — игнорирование и перезагрузка.

Вопросы для самопроверки покрывают все ключевые темы. Рекомендуйте студентам использовать их для подготовки к экзамену.

Основной учебник — Таненбаум. Silberschatz рекомендуется для углублённого изучения темы тупиков и распределённых систем.